Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

global: setup automatic updates and releases #8

Conversation

jorikvankemenade
Copy link
Member

This PR introduces two major changes: the update script and the Travis builds.

Update script

We use the lists from Making Data Count for distinguishing user agents that are either robots or machines. These lists are a manually curated division of the lists from Counter Robots. The problem is that the original list is updated more often than the manually curated one. To mitigate this we updated the update script to always use the latest “Counter Robots” version, and use the “Making Data Count” lists for curating the robots.txt.

Travis builds

Since we can automatically sync with the external libraries it is also nice to automatically release an updated version of the user-agents list. This is done by creating some additional build stages in Travis that can be used for automatically releasing updated versions.

This PR distinguishes three kinds of builds:

  1. Regular build
  2. Cron triggered build
  3. Tagged build

Regular build
For the regular build nothing changes. It runs the tests for Python versions 2.7, 3.5 and 3.6.

image

Cron triggered build
We can set a cron build in Travis that triggers every month. This build will run the update_script. If changes are detected the build is tested and if this is successful the changes are committed, tagged and pushed. This will automatically cause a Tagged build.

image

Tagged build
A tagged build is like a regular build, but with an additional stage. If the test stage is successful a deploy stage will run that will create a deploy in pypi. This allows us to release builds manually, by tagging a release, or via the cron triggered builds.

image

Before merging

Before we merge this PR we must update the secret in .travis.yml. This should be set to the Github token that we have for Invenio i.e. GH_TOKEN=<token>.

After merging

After we have merged this PR we should enable a monthly cron build on the master branch. This will check monthly if there are any updates. If there are updates we will release a new version.

Closes: #7

Copy link
Member

@slint slint left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 Some minor changes and then we have to coordinate adding tokens etc.

.editorconfig Outdated Show resolved Hide resolved
run-update.sh Outdated Show resolved Hide resolved
run-update.sh Outdated Show resolved Hide resolved
run-update.sh Outdated Show resolved Hide resolved
run-update.sh Outdated Show resolved Hide resolved
run-update.sh Outdated Show resolved Hide resolved
.travis.yml Show resolved Hide resolved
@jorikvankemenade
Copy link
Member Author

jorikvankemenade commented Jul 25, 2019

@slint I have applied your suggested changes. I am not sure about your comment about the deploy, but maybe we can quickly discuss that offline.

You also linked docs/developers.rst these might be obsolete. Do we want to remove them, or describe the new procedure there?

@jorikvankemenade jorikvankemenade force-pushed the feature/automatic-release branch 2 times, most recently from 8a9710e to ff25d1b Compare July 25, 2019 15:41
Make-Data-Count uses a non up-to-date version of the COUNTER-Robots
list. However, the differentiation between robots and machines is nice.
To make sure that we have the latest list, but with differentiation we
diff the COUNTER-Robots robots.txt with the machines.txt and
unclassified.txt from the Make-Data-Count repository. If the resulting
classification contains errors, than this must be fixed by opening a PR
at either source repository.

Testruns on Python 2.7 had the following error during pip isntall:

    ERROR: pytest-cov 2.7.1 has requirement pytest>=3.6,
    but you'll have pytest 3.3.2 which is incompatible.

This caused problems during the test. Bumping the pytest version
resolves this.
@jorikvankemenade
Copy link
Member Author

@slint I squashed my changes. Please let me know if I messed up the format or anything. A gentle reminder that we need to change the secret in .travis.yml before merging.

push-update.sh Outdated Show resolved Hide resolved
run-update.sh Outdated Show resolved Hide resolved
@jorikvankemenade jorikvankemenade force-pushed the feature/automatic-release branch 3 times, most recently from 1959632 to 60d1da1 Compare July 26, 2019 11:46
@jorikvankemenade
Copy link
Member Author

@slint @lnielsen this is ready for merging as soon as we changed the GH_TOKEN in .travis.yml.

@jorikvankemenade jorikvankemenade moved this from Pending review to Pending merge in Elasticsearch 7 Sprint (July 22 - Aug 2) Jul 30, 2019
run-update.sh Outdated Show resolved Hide resolved
For the automatic deploy of cron triggered builds we added two scripts
and changed the layout of the travis jobs. The scripts we added:

run-update.sh triggers the update script for the user-agant lists. If an
update is detect the changeg user-agent lists are commited. We also
update the version of the package and create a seperate, tagged, commit
for the release.

push-update.sh adds the remote branch to the current environment
(required for Travis builds) and pushes all changes including tags to
the remote.

For the Travis builds we decided to destinguish three different
situations:
1. Regular build
2. Cron triggered build
3. Tagged build

Regular builds run the test on three different Python versions: 2.7, 3.5
and 3.6

Cron triggered jobs only check if there are updates and do a simple test
before pushing.

Tagged builds first run the Test stage, similar to a regular build.
After succes an addtional stage is triggered, that tests and creates the
release.
@slint
Copy link
Member

slint commented Mar 11, 2020

I'm changing the "update" Travis stage to do the git push ... via using GitHub deploy keys instead of the encrypted GitHub token.

The reason is that the GH token would have to belong to one of the inveniosoftware admins, and thus would have permissions to modify any repository (there's no way to limit the scope of a GH personal access token). Deploy keys provide write access on the repository-level, which is preferred (and doesn't also depend on an actual inveniosoftware org member).

@slint slint moved this from Pending review to Todo in Sprint Week 10-11 (2020) - V3.3 Release Mar 25, 2020
@lnielsen lnielsen closed this Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

global: setup automatic updates and releases
5 participants