search

NASA-PDS / pds-github-util

[ARCHIVED] Github utility functions to enforce the PDS engineering node software life cycle.
https://nasa-pds.github.io/pds-github-util
Other
0 stars 2 forks source link

Documentation on how to tag a release using Github Actions #35

Closed jordanpadams closed 2 years ago

jordanpadams commented 3 years ago

📖 Additional Details

Still not clear how to do this?

The existing manual trigger helps push to pypi, but

MJJoyce commented 3 years ago

The existing manual trigger helps push to pypi, but

  • should the stable_cicd.yaml be removed entirely?

No. This manual build is really only a thin wrapper around PyPI releases to address the chicken and egg problem we were running into. Nominally stable_cicd and Roundup should get used for our builds. It has waaaaay more functionality that we should leverage.

  • does the version number need to be updated in __init.py__ first, and if so, won't that then #trigger the unstable build, which will then fail (or tag a new stable release, which is not what we want to do)?

Yes to both. However, if you're using this the builds should already be broken so it doesn't matter much if another one gets triggered.

Ideally it would do everything that Roundup does without using Roundup (avoiding that whole chicken and egg problem). In its current form the workflow would be something on the order of:

It's just saving you from running the build / dealing with credentials / pushing to PyPI. We could duplicate some / all of the Roundup functionality in this build but it's a non-zero amount of work for a build that (hopefully) will get run very very rarely. The original intention was to completely strip out the Roundup build eventually but it just doesn't seem worth the effort. At worst, we'll run into this "pds-github-util bug is breaking Roundup so I can't build pds-github-util" problem again and need to fix / semi-manually release and push the package.

MJJoyce commented 3 years ago

Also, @nutjob4life ran this manual process the other day so he might have some insight or thoughts on it.

jordanpadams commented 3 years ago

@MJJoyce sorry. i jumped the gun here and removed the stable CICD because it doesn't stop failing. we can re-add once we think it works :-)

jordanpadams commented 3 years ago

The existing manual trigger helps push to pypi, but

  • should the stable_cicd.yaml be removed entirely?

No. This manual build is really only a thin wrapper around PyPI releases to address the chicken and egg problem we were running into. Nominally stable_cicd and Roundup should get used for our builds. It has waaaaay more functionality that we should leverage.

  • does the version number need to be updated in __init.py__ first, and if so, won't that then #trigger the unstable build, which will then fail (or tag a new stable release, which is not what we want to do)?

Yes to both. However, if you're using this the builds should already be broken so it doesn't matter much if another one gets triggered.

Ideally it would do everything that Roundup does without using Roundup (avoiding that whole chicken and egg problem). In its current form the workflow would be something on the order of:

  • Manually update version and tag new release locally. Push to origin
  • Manually create release on GitHub
  • Run the manual build to push to PyPI.

It's just saving you from running the build / dealing with credentials / pushing to PyPI. We could duplicate some / all of the Roundup functionality in this build but it's a non-zero amount of work for a build that (hopefully) will get run very very rarely. The original intention was to completely strip out the Roundup build eventually but it just doesn't seem worth the effort. At worst, we'll run into this "pds-github-util bug is breaking Roundup so I can't build pds-github-util" problem again and need to fix / semi-manually release and push the package.

copy. adding stable CICD back to see if things "work"

MJJoyce commented 3 years ago

:+1: I'll take a look at why it's breaking in a bit. Working on updating Roundup stuff ATM.

MJJoyce commented 3 years ago

I think the changes in the sandbox repos will address this when we reintegrate them.

Roundup now pulls the latest stable version of pds-github-util instead of a pinned version. This means issues like our previous "pds-github-util build fails because of issue we need to fix in pds-github-util" hell can be addressed by:

  1. Updating the state of Sandbox repos
  2. Fixing / Test solution there
  3. Updating the build in the affected repo to use the sandbox build for testing
  4. Reintegrating the changes from the sandbox repos and updating the stable build

Clear as mud?

TLDR: When we merge changes back the workaround release can be removed and this closed out.

jordanpadams commented 2 years ago

Closing per 5b97854