GitHub Actions was introduced in 2019 as a software development workflow automation tool, allowing to automate a wide range of social and technical activities in GitHub repositories. The reusable components known as Actions are developed within GitHub repositories and can be distributed through the GitHub Marketplace. GitHub Actions forms an ecosystem because workflows can rely on reusable Actions, that themselves may depend on other components such as NodeJS packages, Docker images, or other Actions. Just as packages in software library ecosystems have been shown to suffer from a multitude of maintainability issues due to their complex dependency networks, we posit that the same is true for Actions. Therefore, this paper presents preliminary insights in the dependencies of Actions. Based on a dataset of 2,817 Actions, we report on the characteristics of these Actions and we explore to which extent they are developed using JavaScript, Docker or as composite Actions, and to which extent they depend on other components. We show that most Actions are developed using JavaScript, and that composite Actions are gradually replacing Docker Actions. We also show that Actions have many dependencies, especially towards JavaScript packages, resulting in a large number of deeply nested transitive dependencies. This justifies the need for further maintainability studies of the GitHub Actions ecosystem.
Code comprehension, a fundamental asset in software development and its maintenance, is influenced by the programming paradigms employed. Comprehending code takes up a major part of the maintenance process. This study forms a basis in discovering the relation between code comprehension and multi-paradigm usage. The different paradigms covered here are Object-oriented programming and functional programming. To measure the possible impact an experimental setup is designed that will help capturing quantitative and qualitative data. The decision of using interviews as study experiment allows for the capturing of the qualitative data necessary for an in-depth exploration of comprehension strategies and participants’ cognitive reasoning. The interviews will use Kotlin code snippets, this choice harmonises with participants’ familiarity with Java, which serves as a foundation, and the design of interview questions, which prioritise the comprehension of code and the unravelling of its underlying purpose. This paper provides the background and experimental setup that allows to investigate the relationship between code comprehension and multi-paradigm usage.
CI/CD practices play a significant role in collaborative software development. The GitHub social coding platform introduced GitHub Actions as a way to automate different aspects of software production such as testing, building, quality checking, dependency and security management. We report on preliminary findings of a quantitative analysis on how GitHub Actions workflows are being changed over time. The study is based on a dataset of 22,733 GitHub repositories containing 4 million weekly snapshots of workflow files from November 2019 to September 2022. First, we analyse the coarse-grained changes being made to workflows, including when repositories start using them, when they are being added, modified, renamed and removed. Second, we analyse changes made to workflow code, including how many code lines are changed and what types of changes are being made to them. The findings of this quantitative analysis provide preliminary insights on how GitHub Actions workflows are being changed over time, and whether they adhere to the evolution laws of continuing growth and continuing change. It paves the way for studying more evolution laws, as well as more in-depth analyses on the types of changes that CI/CD workflows are subject to as well as the reasons for these changes.
In this paper we explore the possibilities of refactoring code in Whitespace, a programming language which only recognises whitespace characters as code, and tolerates textual comments that describe the program. The paper presents a list of possible refactorings applicable to Whitespace, and describes a tool that automates some of these refactorings. The functionality of the tool is demonstrated with concrete examples. Refactoring is a important systematic process of improving code without creating new functionality, improving long-term properties of the code such as readability, maintainability, changeability, testability, extendability and safety. We argue that, despite the lack of real-life applications for Whitespace specifically, it is beneficial to apply refactoring methodology to it, since lessons learnt from esoteric languages can be ported elsewhere — in this case, to assemblers and similarly restrictive software languages.
Development bots are being used by maintainers of GitHub repositories to perform repetitive or error-prone tasks. While multiple approaches have been proposed in the past to identify such bots in GitHub repositories, they are either inaccurate, not general enough (e.g., based exclusively on specific types of activities) or require a large amount of data that makes it difficult to use them in practice. In this paper, we show that information about the activities performed by contributors in the different software repositories to which they contribute can be used as a basis to distinguish bots from human contributors. These activities can belong to one of 24 distinct activity types such as deleting a branch , creating a tag , publishing a release , opening an issue , commenting on a pull request , and so on. Relying on a dataset of 830K+ activities performed by 713 contributors to GitHub repositories, we identify a number of features allowing to distinguish bots from human contributors. These features are the number of activity types, distribution of inequality in the time taken to perform these activities, distribution of inequality in the number of activity types performed in each repository, ratio between the number of owners and repositories, and the median time taken to switch between repositories to perform another activity. In follow-up work we aim to leverage these features to provide a bot identification model that considers all the activities performed by contributors.
