pulp / plugin_template Goto Github PK

It looks like when using the patchback cherry-pick automation, the merge commit will be cherry picked.

Since the merge commit does not contain the issue reference in the commit message, the so opened PR will then fail the commit message validation as follows: pulp/pulp_deb#483

• One possible solution is to change the pulp_deb repo settings to stop using merge commits (and use manual cherry-picks until then).
• Another possibility would be to always add the issue reference in the merge commit message going forwards.
• The final option would be to have the automation cherry-pick not the merge commit, but the individual commits on the PR being backported.

The GHA automation from the plugin template produces a dev version number like 3.17.0.dev which is not semver compatible nor is it Python version spec compatible, see pre releases.

It would be good if our pre releases used Python compliant versions.

All functional tests should be run from inside the container. The PYTHONPATH should no longer need to be manipulated. Functional test requirements should only be installed inside the container.

Right now the workflow tries to update all branches going back to a certain one. The workflow should only update branches that are part of a list of supported branches.

We encountered a problem when releasing 3.14.1 when trying to cherrypick the changelog back to master:

https://github.com/pulp/pulpcore/runs/3011763886?check_suite_focus=true#step:23:37

I believe the problem is that due to a z-stream release, the changelog commit is referencing (and trying to remove) changelog files that don't exist on master. For example, there's CHANGES/9015.bugfix which is the 3.14.1 backport of CHANGES/9003.bugfix.

I just ran into a problem with the changelog during release workflow. In my case there were two changelog entries that were causing a problem. CI for every PR should try to run towncrier to generate a changelog and then build the docs using sphinx.

The idea is that the PR CI can set (clear) labels about the state of the commits.

• noissue in case, any commit message contains [noissue] - reviewers should take extra care if those commits are suitable for not having an issue
• multi-commit in case the PR contains more than one commit - reviewers should judge if the changes suitable to be split into seperate commits, and occasionally request to split the PR or merge the commits

Simple PR's would not have these labels.

When I change the name of a branch in template_config.yml, one of the workflows should be updated as well:

 plugin_caps_short: OSTREE
 plugin_dash: pulp-ostree
 plugin_dash_short: ostree
-plugin_default_branch: master
+plugin_default_branch: main
 plugin_name: pulp_ostree
 plugin_snake: pulp_ostree
 post_job_template: null

       - name: Cleanup repository before making changelog PR
         run: rm -rf .lock generation pulp_ostree_client* *-client.tar pulp_ostree.tar todo web docs.tar
 
-      - name: Stage changelog for master branch
-        run: python .github/workflows/scripts/stage-changelog-for-master.py ${{ github.event.inputs.release }}
+      - name: Stage changelog for main branch
+        run: python .github/workflows/scripts/stage-changelog-for-main.py ${{ github.event.inputs.release }}
 
       - name: Create Pull Request for Changelog
         uses: peter-evans/create-pull-request@v3

 
 helper = textwrap.dedent(
     """\
-        Stage the changelog for a release on master branch.
+        Stage the changelog for a release on main branch.
 
         Example:
-            $ python .github/workflows/scripts/stage-changelog-for-master.py 3.4.0
+            $ python .github/workflows/scripts/stage-changelog-for-main.py 3.4.0
 
     """
 )

The release workflow used to create a python-client-docs.tar which is then used during the publish stage to publish the python client docs.

537 below refers to a github issue and not a pulp.plan.io issue. The script needs to use the right issue tracker.

Bugfixes
--------

- Fixed "manifest_id" violates not-null constraint error during sync.
  `#537 <https://pulp.plan.io/issues/537>`_

Migrated from https://pulp.plan.io/issues/6299

plugin_template should have a test to assert if setup.py.j2 has the latest pulpcore version as requirement https://github.com/pulp/plugin_template/blob/master/templates/bootstrap/setup.py.j2

The CI uses Python 3.7 but attempts to install pulpcore which requires 3.8+:

ERROR: Package 'pulpcore' requires a different Python: 3.7.11 not in '>=3.8'

In cases where docs need to be fixed after a release, a post_before_script.sh can be used to checkout the correct docs. The release workflow needs to accept an optional parameter that can be used to populate the content of the post_before_script.sh.

Migrated from https://pulp.plan.io/issues/9028

The milestone is left open even though all issues are at closed current release. The state of the milestone itself can be set to "closed"

The release workflow should close issues that are mentioned in the CHANGES directory.

Migrated from https://pulp.plan.io/issues/6721

This section should contain the configuration for flake8 and if possible black. That way we can keep those configurations consistent and updated in all repositories that opt in to comply to the same linting rules.

This may also be important for files that are not related to linting. All files that are meant to be updated with plugin-template should not be in the "bootstrap" section. And the on the other hand for example the doc stubs that are meant to be filled by the plugin writer should move to the "boostrap" section while the docs-building machinery should be an updateable section.

When using Github issues, towncrier is able to link changelog entries to the PR. So having an issue for each PR is less essential. We should allow the changelog to use the PR #. Check out this simple example from towncrier where 338 is the PR #.

Current validation

Today, the current validation is:

• Check if the commit references any issues
  • If so, check that the issues are open and have changelog files in the CHANGES directory
• Else, check if the commit has [noissue] in it
  • If not, fail the check

Proposal

I'd propose we modify the current behavior a bit:

• Check if the commit references any issues
  • If so, check that the issues are open and have changelog files in the CHANGES directory
• Else, check if the commit has [noissue] in it
  • If not, check that there's a changelog for the current PR #
    • If there's no changelog entry, fail the build

This would allow us to not have to specify [noissue] in cases where there's no issue but we still have a changelog entry which corresponds to the PR #.

Migrated from https://pulp.plan.io/issues/6722

When I try to set a branch for an additional repo to a commit, like this:

additional_repos:
- bindings: true
  branch: bd9da19910dde6340cf38900e20beaad025319ec
  name: pulp_ansible
  org: pulp

Our CI fails with the following error:

git clone --depth=1 https://github.com/pulp/pulp_ansible.git --branch bd9da19910dde6340cf38900e20beaad025319ec
Cloning into 'pulp_ansible'...
warning: Could not find remote branch bd9da19910dde6340cf38900e20beaad025319ec to clone.

Migrated from https://pulp.plan.io/issues/8754

Here is the example of the commit that is not being cherry-picked pulp/pulp_rpm@2a0bfe6

Cherry-pick script supports only fixes and closes keywords but not re or ref.

The problem with adding those to the list of the keywords is that the pattern becomes too generic, especially re. And sed will match more than needed.

The workaround is too cherry-pick manually, or add re and ref to the list of keywords and fix the commit message if there are extra subs made.

For now, we will just reroute the container in the s3 test environment.

Migrated from https://pulp.plan.io/issues/5456

In the travisscripts, the commit messages of a pr are checked to conform to a specific format. If they do not conform, the scripts fail very early skipping all 'real' tests.
This makes it impossible to add incremental changes in individual commits (later to be squashed) to an existing PR while stilll get reports for failing tests.
If commit message validation was extracted as a separate test, one could use for example the git commit --fixup aabbccdd feature of git, while the validator would still block the merge button.

The 'generate-bindings' test is supposed to only generate bindings and not run any tests.

After a release is published to PyPI, the changelog needs to be added to the master branch of the repository.

The cherry-pick script needs to generate a link for the issue number from which the backport was created.

To allow for quicker test running in the CI, it would be good to split the single call to the functional tests into two calls. The first should collect all tests marked with parallel and run those using the -n param provided by pytest-xdist. After that it should collect all tests not marked with parallel and run those just like it does today.

The release workflow is changing the required pulpcore version in the commit that bumps the version of the plugin. The required version of pulpcore should not change.

Author: daviddavis (daviddavis)

Redmine Issue: 6938, https://pulp.plan.io/issues/6938

I was talking to ggainey about some of the automation checks we have in pulp (commit validation, style/lint checks, changelog, etc) and how it might be frustrating for new devs. I've heard the same feedback from other contributors such as galaxy.

We need to provide an easy way for developers to run our CI checks locally. I've seen other projects (bandersnatch[0], black[1], celery[2], etc) use pre-commit:

https://pre-commit.com/

[0] https://github.com/pypa/bandersnatch/blob/master/.pre-commit-config.yaml

[1] https://github.com/psf/black/blob/master/.pre-commit-config.yaml

[2] https://github.com/celery/celery/blob/master/.pre-commit-config.yaml

The container is ran in debug mode causing the entire settings file and traceback to be printed after each test failure. If more than one test fails the logs become practically impossible to traverse. Remove debug=True and just have the settings file be printed in the after failure section.

Expiring PRs makes sense after weeks / months of no movement, but expiring issues really doesn't. Especially since we've been actively pruning outdated issues manually so there aren't that many of them remaining - most of the issues currently marked as "stale" by stalebot are completely valid.

It seems that closing and reopening the PR seems to trigger the Actions though.

More info: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#triggering-further-workflow-runs

Instead of producing a traceback like below, a proper error message should state "Couldn't find milestone x.y.z".

Repo path: /home/runner/work/pulp-certguard/pulp-certguard
Traceback (most recent call last):
  File ".github/workflows/scripts/release.py", line 61, in validate_and_update_redmine_data
    issue_milestone = redmine_issue.fixed_version
  File "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/redminelib/resources/standard.py", line 152, in __getattr__
    return super(Issue, self).__getattr__(attr)
  File "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/redminelib/resources/base.py", line 197, in __getattr__
    raise exceptions.ResourceAttrError
redminelib.exceptions.ResourceAttrError: Resource doesn't have the requested attribute

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File ".github/workflows/scripts/release.py", line 288, in <module>
    release_commit_sha = create_release_commits(repo, release_version, plugin_path)
  File ".github/workflows/scripts/release.py", line 132, in create_release_commits
    redmine_final_query, issues_to_close, release_version
  File ".github/workflows/scripts/release.py", line 66, in validate_and_update_redmine_data
    redmine.issue.update(redmine_issue.id, fixed_version_id=milestone.id)
UnboundLocalError: local variable 'milestone' referenced before assignment```

When I set

pulpcore_branch: main
pulpcore_revision: ea3b9c42a2a7a63e6292d94fa05173f178101076

In template_config.yaml, the plugin template generates the following:

git clone --depth=1 https://github.com/pulp/pulpcore.git --branch main

cd pulpcore
git checkout ea3b9c42a2a7a63e6292d94fa05173f178101076

This breaks with the following error: fatal: reference is not a tree: ea3b9c42a2a7a63e6292d94fa05173f178101076.

This seems to happen because --depth=1 only pulls the latest commit. Running git log after cloning the repo only shows the latest commit, which causes checkout to break when it's set to any commit other than the latest one in the specified branch.

Migrated from https://pulp.plan.io/issues/8677

Migrated from https://pulp.plan.io/issues/6722

Migrated from https://pulp.plan.io/issues/7748

For every feature and/or bugfix enforce test requirement in Travis CI add a new option 'enforce_tests'

Extract relevant pieces of code from this PR https://github.com/pulp/pulp_rpm/pull/1857/files#diff-8c6562995f4cd50218a49fa26339777535cf82bd175479d4c4bdb33e87df37c9R21

This is a transformation of https://pulp.plan.io/issues/9361

The new workflow should triggered manually from master branch. It needs to take a name parameter. The workflow needs to check that the branch name matches up with the current version on master branch. If the name of the branch and the X.Y portion of the version string match, the workflow should create a new branch that is exactly like master and then bump the version on master and open a PR with that version bump.

Allow custom lint checks in plugins, stemming from galaxy_ng running into orphan_protection_time set to 0 (can result in a race condition). We would like to avoid forgetting this in the future and have a place to add similar checks.

Happens during the "Update Redmine" step during publish, so most of the release has already happened (packages are updated on pypi and rubygems, etc.).

The error encountered is:

python3 .ci/scripts/redmine.py $REDMINE_QUERY_URL $MILESTONE_URL $RELEASE
Traceback (most recent call last):
  File ".ci/scripts/redmine.py", line 27, in <module>
    status = redmine.issue.get(int(issue)).status.name
ValueError: invalid literal for int() with base 10: ''

See here for the full workflow: https://github.com/pulp/pulp_deb/runs/4223060338?check_suite_focus=true

Expectation:

If there are no issues in the release, then .ci/scripts/redmine.py does not need to do anything, and should just return 0!

Release steps not performed because they come after the error:

• Create release on GitHub
• Cleanup repository before making changelog PR
• Stage changelog for master branch
• Create Pull Request for Changelog

=> The changelog steps might also need some special handling to deal with this special case of "no changelog entries".

Migrated from https://pulp.plan.io/issues/7608

Nightly integration testing with Katello requires Pulp publishing nightly pre-releases. Plugin template needs to provide an optional stage for such deployment. This stage needs to also clean up any pre-release builds that are older than 30 days.

Migrated from https://pulp.plan.io/issues/5107

Inspired by pulp-smash's Makefile:

https://github.com/pulp/pulp-smash/blob/master/Makefile

It would be nice to have something similar for plugins to provide an easy and standardized way to create commands.

The CI uses the pulp_ci_centos image which already has a version of Python installed. Currently, that's Python 3.8. However, we're still releasing older versions of pulpcore and plugins that support Python 3.6 and we need a way to have our CI test against Python 3.6.